Aspects of the present invention relate in general to message oriented middleware (MOM), and more particularly to managing queues in a data processing system employing asynchronous messaging.
In recent years, the ability of application programs to communicate with each other or with system provided services in a computer system or network without having to become involved in the complexities of particular operating systems or communication protocols has been much enhanced by the development of Message Oriented Middleware (MOM). This is software providing a common programming interface by means of which applications can communicate with other applications without specific knowledge of the different operating systems and/or protocols which may be used by those applications.
One example of Message Oriented Middleware is the IBM WebSphere MQ product family (“IBM” and “WebSphere” are trademarks of International Business Machines Corporation). A comprehensive description of one of these products is contained in the book “WebSphere MQ V6 Fundamentals” (SG 24-7128, November 2005), also available via the Internet.
WebSphere MQ and other MOM products employ message queuing which allows programs to send and receive application specific data to each other without having a private, dedicated logical connection established between them. Instead, messages containing the application specific data are placed on queues by a queue manager local to the application. These queues may be accessed directly by applications on the same system using the same queue manager or their contents may be transmitted over a network or multi node system and placed on respective associated queues accessible to a receiving application via its respective local queue manager. In order to transmit messages to remote applications, the originating queue manager must first establish a communication channel to the remote queue manager. Both transmission and accessing of queued messages take place asynchronously.
Applications communicate with their associated queue managers via a standard application programming interface (API), known as the Message Queuing Interface (MQI) in the case of WebSphere MQ. Specific API commands cause the queue manager to store (PUT) messages on named destination queues, either directly, if local, or by transmitting them to the appropriate queue manager at a node elsewhere in the system and also to retrieve (GET) stored messages from such queues. A queue can be both a source of messages and a destination for messages.
In a large data processing system having multiple processor nodes or a heterogeneous network of different processors, some of which may be physically remote from each other, there may be a queue manager at each node. In this case, each queue manager must be aware of or capable of discovering the location of all the others in the network or system and be capable of determining whether it owns the destination queue for a received message or, if not, how to send it on towards a destination queue on another queue manager.
Currently, if incorrect, faulty or incomplete data has been sent in the application data part of a message, for example a faulty order form, it will still be retrieved and processed by the application owning the destination queue. If the message contains built in exception/error handling procedures, the receiving application may be able to inform the source application or to take a user exit. It is also possible that, if the data in the source application message was entered by a human user, that user may recognise and wish to correct the message data content. Such situations are currently remedied by sending further messages to correct or change the actions already taken by the receiving application.
However, this inevitably causes delay as time is wasted in that the receiving application has to process both the faulty and the compensating or correcting message.